MICROSCOPE COURTESY OF OPTICAL SYSTEMS DIVISION OF CAMBRIDGE INSTRUMENTS 


COVER SUITE: 


DIAGNOSING 
PROBLEM CODE 


Turbo 
Debugging 


Borland has added the missing ingredient to its product 
line with Turbo Debugger. It challenges Microsoft CodeView's 
preeminence among high-level language debuggers. 


generation of PC software devel- 

Ave: cut their teeth on the ven- 

erable DOS DEBUG. Initially, it 
was the only debugging tool around, 
but the market soon exploded. 

Today, a wide array of debuggers 
is available. The most significant recent 
development in the market is Borland’s 
Turbo Debugger, which could attract 
users of not only Borland’s languages, 
but also Microsoft's languages. 

Since the early days of DEBUG, 
the debugger market has evolved into 
five broad, nonexclusive classes: as- 
sembly-language, symbolic, high-level 
language (into which Turbo Debugger 
falls), hardware-assisted, and in-circuit 
emulator (ICE) debuggers. 

Assembly-language debuggers, of 
which DEBUG is the most famous and 
widely used example, work solely with 
machine code. Software developers 
writing in high-level languages cannot 
easily correlate source code with com- 
piled assembly code. They must resort 
to tricks such as including program 
statements to write out values of critical 
variables during program execution. 
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With more complex applications, 
developers demand more sophisticated 
tools. Symbolic debuggers improve on 
assembly-level debuggers by using 
linker .MAP files or symbolic informa- 
tion embedded in the object-code file 
to relate assembly-level addresses to 
variables or functions. Disassembled 
code shows variable and function 
names, rather than hexadecimal oper- 
ands. Microsoft's SYMDEB, introduced 
in 1985, is a symbolic debugger. 

High-level language debuggers go 
one step further than symbolic debug- 
gers by simultaneously displaying 
source and assembly code so that the 
logical relationship between them is 
readily apparent. The machine code is 
disassembled in clear relation to vari- 
ables and functions, and developers 
can debug individual high-level lan- 
guage statements. _ 

Microsoft's CodeView, introduced 
in late 1986, is the most popular high- 
level language debugger—and the one 
with which Turbo Debugger will com- 
pete most directly. Though primarily 
menu and window oriented, CodeView 


is downwardly compatible with the 
older command-line oriented debug- 
gers, DEBUG and SYMDEB . (For a re- 
view of CodeView, see “Multilevel De- 
bugger,” Mark S. Ackerman, March 
1987, p. 90.) 


Rounding out the list are the hard- 


ware-assisted debuggers and the ICEs. 
These products are the most sophisti- 
cated and expensive PC debuggers. 
Hardware-assisted debuggers typi- 
cally control and monitor the debug- 
ging process with an expansion board 
installed on the bus. They are more 
flexible than their software counter- 
parts because their hardware break- 


points do not affect the speed of a pro- 


gram; furthermore, they can run pro- 
grams in protected memory, which can 
prevent the need to reboot when a 
piece of code hangs the system. More- 
over, the software developer can usu- 
ally break out of a feisty program with 


a break button. ICEs have the same fea- 


tures as hardware-assisted debuggers 
but are more expensive because they 
consist of outboard hardware that re- 
places the PC’s processor. 
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TURBO DEBUGGER 


The second article of this month’s 
cover suite (“Hardware Assistance,” 
Marty Franz, p. 58) examines hardware 
debuggers and looks at two in detail: 
Atron’s 386 Source Probe and The Peri- 
scope Company's Periscope III. 


TURBO ERGONOMICS 

In August 1988, Borland International 
announced its high-level language de- 
bugging environment, Turbo Debugger 
1.0, which began shipping in late Sep- 
tember. Borland simultaneously intro- 
duced Turbo Pascal 5.0, Turbo C 2.0, 
and a package containing both Turbo 
Assembler and Turbo Debugger. In 
addition to other new features, both 
Pascal and C now have an integrated 
source-level debugger. Borland also of- 
fers two packages—Turbo Pascal Pro- 


HELP FROM THE HARDWARE 


All 80x86 processors have two fea- 
tures that help developers implement 
debuggers: the breakpoint instruction 
and single-step execution. The break- 
point instruction, INT 3, has a one- 
byte operand code (OCCH), not the 
two-byte form used by other interrupt 
instructions. Because an INT 3 is one 
byte long, it can replace the first byte 
of an instruction without corrupting 
subsequent ones (see Tech Notebook, 
this issue, p. 121). 

When a program executes INT 3, 
the CPU transfers control to the 
breakpoint interrupt vector at low- 
memory location 0CH; the debugger 
will have previously set this vector to 
a debugger entry point. The CPU 
saves the code segment (CS) and the 
instruction pointer (IP) flag registers 
on the stack, with the IP pointing just 
past the INT 3 instruction. 

To set an unconditional break- 
point, the debugger saves the break- 
point address and the byte of code at 
that address, then inserts an INT 3 
there. When an INT 3 occurs, the 
debugger takes control and puts back 
the first byte of the instruction. Then, 
the user can issue commands to in- 
spect or change program variables. 

To resume execution at break- 
point, the debugger subtracts a value 
of one from the IP on the stack and 
does an IRET to execute the original 
instruction. The program runs under 
its own control until the next break- 
point occurs. Because the debugger 
executes only when a breakpoint is 
reached, the mechanism for uncondi- 
tional breakpoints does not degrade 
program execution time significantly. 
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fessional and Turbo C Professional— 
that bundle Turbo Assembler and 
Turbo Debugger with Turbo Pascal 5.0 
and Turbo C 2.0, respectively. 

Borland paid considerable atten- 
tion to human factors when it designed 
Turbo Debugger’s interface. The pack- 
age is entirely menu driven—from the 
installation and customization programs 
to the debugger itself. By contrast, 
CodeView is a more cumbersome hy- 
brid that uses both commands and 
pull-down menus. 

-Turbo Debugger has more than 
200 hot keys and main- and local-menu 
commands. Despite this intimidating 
number, developers can easily navigate 
the program through the windows in- 
terface and its pop-up data-entry and 
selection boxes. 


The second feature that aids trac- 
ing on Intel processors is single-step 
execution. The debugger enables this 
feature by setting the trap flag (TF) in 
the flags register. Whenever the TF is 
set, the processor transfers control to 
the address in the INT 1 vector (at 
location 4 in low memory) after exe- 
cuting each instruction. Single-step 
execution is slower than normal exe- 
cution, often by a factor of 100. 

Implementing conditional break- 
points using only these two features 
is laborious. If the user wants to 
break program execution based on 
the change of a variable in memory, 
the debugger must execute the ‘pro- 
gram entirely in single-step mode. 
With each single-step interrupt, the 
program checks the variable being 
monitored for a change, and, if no 
change has occurred, executes the 
next instruction. 

For conditional breakpoints set at 
source level, a well-designed debug- 
ger can run somewhat faster by in- 
serting breakpoints at the first assem- 
bly instruction generated for each 
line of source code. A breakpoint- 
handling procedure tests the variable 
and continues program execution if 
no change is found. Conditional 
breakpoints based on the value of the 
expression are handled in much the 
same way. When a debugging inter- 
rupt occurs, the debugger evaluates 
the parsed expression to see if it is 
true and acts accordingly. 

Additional debugging help comes 
from the 386 processor’s ability to set 
four hardware-monitored breakpoint 
addresses. Debugging software can set 


The main screen has a menu bar 
across the top to access primary func- 
tions, such as working with files, setting 
breakpoints, and running programs. 
The bottom line displays context-sensi- 
tive, function-key actions that vary for 
each window. When the user presses 
the Alt key, the bottom line shows ad- 
ditional options available using Alt with 
various key combinations. Pressing the 
Ctrl key shows the local commands, 
initiated by Ctrl combined with letter 
keys. Borland calls these commands 
local because they initiate actions in 
the current window. 

Borland extends the window meta- 
phor further with panes, which are log- 
ical subdivisions within a window. The 
tab key allows movement from pane 
to pane within any window. Progress 


a breakpoint for instruction execu- 
tion, data writes, or data reads and 
writes; data breakpoints can be one, 
two, or four bytes wide. 

Unlike the INT 3 instruction, 386 
breakpoints do not modify the code 
to set an instruction breakpoint, and 
they can be set on data accesses. 
Breakpoint interrupts for this feature 
occur on the INT 1 vector; the 
single-step interrupt is still supported 
by the 386 on this vector, so the CPU 
provides a status register to give the 
reason for the interrupt. 

Although the 386 debug registers 
are a welcome addition to the tools 
for a debugger, they still leave a great 
deal of work for the debugger de- 
signer. This is especially true in 
multitasking environments such as 
Unix and OS/2. For example, the 
debug registers are not stored in the 
task-state segment; therefore, the soft- 
ware must explicitly save and restore 
them when more than one task is 
being debugged. 

A major element in the design of 
a 386 debugger is how to make best 
use of the four sets of debug regis- 
ters. Watching data entirely with soft- 
ware is many times slower than with 
the 386 debug registers. Thus, the 
design of a 386 debugger favors 
watching data through the debug reg- 
isters whenever possible. If the de- 
bugger allows more than four concur- 
rent breakpoints, a combination of 
INT 3 and single-step interrupt hand- 
lers must suffice for the excess that 
cannot be accommodated by the 386 
debug registers. 

—Ben Myers 
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through windows already opened is 
even faster using history lists, which 
store the last sequence of choices 
made in the current session. As a short 
cut, pressing the Alt key and the win- 
dow number selects an open window. 


DEBUGGING ENVIRONMENTS 
Unlike CodeView, Turbo Debugger has 
built-in support for a variety of hard- 
ware. It supports four different debug- 
ging environments: 8086 mode, 386 vir- 
tual mode, remote, and hardware- 
assisted debugging. In all modes, the 
Turbo Debugger user can step through 
statement execution, with or without 
dropping down into function calls, at 
both source-code and assembly levels. 

' To use the virtual-memory fea- 
tures when debugging on a 386, the 
user must install the TDH386.SYS 
driver in CONFIG.SYS and then run the 
386 virtual debugger, TD386. TD386 
runs entirely in extended memory, al- 
lowing the program being debugged 
(target program) to load and run at the 
virtual memory address it would use in 
actual conditions. The 386 device 
driver permits the developer to set 
hardware breakpoints for instruction 
fetches, memory reads, and read/write 
memory accesses at specified addresses 
(see the sidebar at left, “Help from the 
Hardware’’). 

The target program can use 80286 
and most 386 instructions, except for 
those that operate in protected mode. 
A toggle changes the display between 
the 32-bit 386 extended registers or 
16-bit registers. 

The virtual-8086 mode and mem- 
Ory management make the system prac- 
tically immune to crashes, even if the 
target program destroys memory con- 
tents within its own address space. 
These same features, however, slow the 
program down and cause timing prob- 
lems for some applications. 

When a 386-based PC is not avail- 
able or memory is at a premium, 
Turbo Debugger’s remote debugging 
interface program, TDREMOTE, is a 
useful alternative. Turbo Debugger runs 
on the first machine, and TDREMOTE 
and the target program run on the sec- 
ond, effectively insulating the debugger 
from crashes. TDREMOTE requires only 
15KB of memory, permitting the devel- 
oper to debug large programs (see 
table 1 for a comparison of Turbo De- 
bugger and CodeView target-program 
sizes). Setting up to debug a program 
in a remote PC is a relatively simple 
process. TDREMOTE and Turbo Debug- 
ger communicate through serial ports 
interconnected by a null modem cable. 
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TABLE 1: Turbo Debugger and CodeView Comparison 


PRODUCT 
VERSION 
DEBUGGING PROGRAMS 

Compiled with /Zi (TDCONVRT) 
With MAP files (TDMAP) 


OS/2 

Microsoft Windows 

Turbo C 2.0 and Turbo Pascal 5.0 
OTHER DEBUGGING FEATURES 
Views 32-bit 80386 registers 


Has remote debugging 

Uses command macros or files 

Logs output 

Views data structures in source format 
Integrates use of mouse for commands 
Uses expanded memory 

Reports own and target’s EMS usage 


8088, 8086, or 80286 
80386 
Remote PC 


@= Yes 90=No MA=Not applicable — 


with Microsoft. 


Supports other languages with MAP files 


Uses 80386 hardware debugger features 
Documented hardware debugger support 


Searches for instructions in assembly code 
MAXIMUM SIZE OF PROGRAM AND DOS (KB) 


“ CodeView for Windows applications is available with Windows 2.1 Software Development Kit. 
» The CodeView file format is available to developers who enter into a contractual agreement 


© Command macros cannot be saved between debugging sessions. 
4 Screen output is redirected to a file and is not visible to the user. 


MICROSOFT 


Turbo Debugger CodeView 
1.0 22 
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Turbo Debugger offers users of Borland languages the functionality of Microsoft’s 
CodeView, with many added features including Borland’s use of the 386’s 
memory-management and debugging features and innovative remote debugging. 


TDRF, a program running the ma- 
chine used for the debugger, supports 
file transfer between Turbo Debugger 
and the target PC. TDRF transfers data 
at 9,600, 40,000, or 115,000 bits per 
second (bps) and permits normal DOS 
functions such as file deletion and re- 
naming, directory creation, deletion, 
and listing on the remote computer. 

Borland provides documentation 
for writing device drivers for interfac- 
ing Turbo Debugger to hardware de- 
buggers so that memory- and I/O- 
access breakpoints produced by the 
board are handled by Turbo Debugger. 
No vendors are yet shipping a compati- 
ble hardware driver, although several, 
including Atron and Periscope, are con- 
sidering such a product. Borland says 
the interface eventually will support in- 
struction trace-back and extra onboard 
memory for a symbol table. 

If vendors of hardware debuggers 
provide their own drivers to meet the 
Borland debugger driver specification, 


the promise of well-integrated hard- 
ware and software debugging will be 
realized. Several hardware debugger 
manufacturers support CodeView for- 
mat files under license agreements 
with Microsoft. , 

Turbo Debugger can use EMS 3.2 
or 4.0 to store its symbol tables, and it 
keeps track of expanded memory used 
by the program being debugged. Ex- 
panded memory is used for symbol 
tables only; no executable code is 
loaded in EMS. On 386-based PCs, 
Turbo Debugger runs the target pro- 
gram in 1MB of virtual 8086 space 
(640KB of program space) and uses the 
386 memory-protection hardware to 
keep the target program from contami- 
nating the rest of the environment. 
Through 386 microprocessor capabili- 
ties, Borland has given the developer 
much of the functionality of a hardware- 
assisted debugger. CodeView users can 
get 386 functionality with MagicCV, an 
add-in product from Nu-Mega. 
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While Turbo Debugger supports 
Borland’s language compilers and as- 
sembler, developers also can debug 
programs written in Microsoft lan- 
guages at the source level, using the 
TDCONVERT facility included with the 
debugger. The program converts Micro- 
soft .EXE files compiled for CodeView 
into the Borland .EXE format. 

Turbo Debugger works with most 
compilers and linkers that produce de- 
tailed .MAP files by using the included 
TDMAP utility to append Turbo Debug- 
ger information to the .EXE file. Turbo 
Debugger, however, operates only 
under DOS, not OS/2, and cannot 
debug programs compiled for the 
Microsoft Windows environment. 
Microsoft, on the other hand, has 
added OS/2-specific features to Code- 
View (see the sidebar, “CodeView 
Under OS/2: Nice Threads’). 


GETTING UNDERWAY 

Installation of the three Turbo Debug- 
ger diskettes takes only a few minutes 
with the menu-driven INSTALL pro- 


gram, which automatically unpacks 
compressed files. The TDINST program 
controls several customization parame- 
ters; the user can change many while 
Turbo Debugger is running. 

Customization options include 
choosing window colors; specifying 
editor, source, and debugger direc- 
tories; enabling remote debugging and 
use of EMS; selecting the language syn- 
tax used for expression evaluation; and 
selecting how display video pages are 
managed between the debugger and 
the user screen. 

TDINST has several options for 
handling screen swapping between the 
debugger and the executing program’s 
(user) display screen image. If the sys- 
tem has multiple display pages, as in 
the CGA, EGA, or VGA, the Turbo De- 
bugger screen will be maintained on a 
separate display page. The user can 
also swap screens in software—a 
slower, but less disruptive method. 

A second monitor can display 
Turbo Debugger while the first displays 
the user screen. TDINST permits the 


CODEVIEW UNDER OS/2: NICE THREADS 


While Borland was busy creating 
Turbo Debugger, Microsoft was work- 
ing to add OS/2-specific features to its 
existing CodeView debugger. In most 
respects, CodeView is unchanged 
since we last reviewed it (see “Multi- 
level Debugger,” Mark Ackerman, 
March 1987, p. 90). However, Micro- 
soft C 5.1 includes a major enhance- 
ment to CodeView that facilitates 
OS/2 debugging—support for multi- 
threaded applications. 

The OS/2 environment refines 
multitasking within a process to a 
thread level, OS/2’s fundamental unit 
of scheduling. Unlike an individual 
process that has its own data space, 
an OS/2 thread shares the process 
environment of its parent. Starting a 
program under OS/2 actually invokes 
an instance of the program as thread 
1. Thereafter, thread 1 can start other 
threads (for example, threads 2, 3, 
and so on). 

The behavior of CodeView’s stan- 
dard commands is affected by these 
threads. For example, a breakpoint 
that is set with the BP command will 
stop when any thread reaches the 
breakpoint. Other commands, such as 
Trace, Step, and Execute, apply to the 
current thread, but also allow other 
threads to run concurrently. Thus, an 
Execute command will run the cur- 
rent thread in slow motion, but OS/2 
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can schedule other threads that could 
preempt that thread. Similarly, a Trace 
command will execute a single in- 
struction in the current thread, but 
OS/2 may also run many instructions 
in other threads before it returns to 
CodeView. 

To reflect the multiple-thread na- 
ture of OS/2, CodeView uses a com- 
mand prompt that displays the num- 
ber of the current thread, which is the 
thread currently selected for debug- 
ging (for example, 001>). Because 
every thread has its own stack and 
register set, the display changes to 
reflect new values any time the current 
thread is changed. Note that CodeView 
controls and monitors just the threads 
in the program being debugged; 

OS/2 schedules other threads in the 
system in the normal way. 

For detecting elusive bugs in 
multithreaded programs, developers 
need precise control over threads. 
Help comes in the form of the thread 
command, ~ (the tilde character), to 
control execution of specific threads. 
The command has two fields. The 
first field specifies the thread to be 
Operated upon: 


n thread number 7; 

# the last thread executed; 

* all threads in the program; 
the current thread. 


user to update screens continuously, 

when a change occurs, or not at all. 
The commands TD or TD386 fol- 

lowed by command-line options and 


| the target program name starts Turbo 


Debugger. Commands follow either 
Unix style (preceded by a hyphen) or 
the DOS convention (preceded by a 
forward slash). An —h or —? displays 
all command-line options. 

Source-level debugging requires 
programs compiled or assembled with 
the following options. For Borland’s 
Turbo languages, the /y command-line 
Option or its menu equivalent instructs . 
the compiler to include debugging in- 
formation in the .OBJ file. Microsoft 
languages that support CodeView re- 
quire the /Zi option as if CodeView is 
the debugger. TDCONVRT then con- 
verts the resulting .EXE files. For prop- 
erly linked and compiled programs, 
Turbo Debugger presents a source- 
code window, which displays the first 
executable lines of source code. Other- 
wise, the package displays disassembled 
machine language. 


The thread command’s second 
field is a subset of the CodeView 
commands: BreakPoint, Execute, Go, 
Program Step, and Trace. Three other 
commands are also recognized. The 
Select command changes the current - 
thread to the one specified. The 
Freeze command disables threads so 
they will not run in the background. 
Freezing all but the current thread, 
for example, ensures that only the 
thread being debugged runs during a 
specific section of code. The Unfreeze 
command reverses the effect of the 
Freeze uncommand. 

The thread command is power- 
ful, but painfully cryptic. For example, 


Show status of all threads 
Freeze all threads 
Unfreeze thread 3 

Run all unfrozen threads 
Make thread 2 current 

Set a breakpoint for thread 
2 at line 53 


parti ee 


CodeView has strong debugging 
abilities for OS/2, but they certainly 
look clumsy when compared with 
Borland’s Turbo Debugger. If Micro- 
soft intends for CodeView to reign 
supreme under OS/2, the company 
needs to send its debugger in for an 
overhaul before Borland hauls Turbo 
Debugger over to OS/2. 

—David Methvin 
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PHOTO 2: Viewing Variables 
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PHOTO 1: Setting Breakpoints 
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testerr{i] := testerr[1]/5.6 ; 
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A few keystrokes can set a breakpoint, run the program, 
trace the execution at the breakpoint, add another condi- 
tional breakpoint, and review current status in seconds. 


{error is average absolute error per elenent} 
if err{1] > MINERR then logerr{1] := -Inferr[1]) » LOGIOE 


:= LOGHIN: 
:= testerr{1] + (LOGHIN - logerrfl]) ; 
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A listing of all the variables in the program ACCURACY.PAS 
is only two keystrokes away—AlIt-V, V. The right pane 
shows global variables; the left pane shows local variables. 


Turbo Debugger has many options 
for running target programs. One pos- 
sibilitysis to execute a single instruc- 
tion, what Borland calls the trace-into 
function. This selection executes one 
instruction at a time, including calls. 
When traced, a call is executed and the 
window displays the code within the 
called function or procedure. Turbo 
Debugger also has a step-over function 
that executes the call and returns to 
the instruction following the call, treat- 
ing the call as one logical instruction. 

Another alternative is animation, 
which runs the program in slow mo- 
tion, highlighting each instruction as it 
executes. Animation continues until the 
program encountérs a breakpoint, ter- 
minates, or is interrupted by the Ctrl- 
Break keystroke combination. The user 
can set the time interval between ani- 
mated instructions (0.3 of a second is 
the default). 

Manipulating breakpoints is an 
easy proposition. The user sets break- 
points with either a single keystroke 
or from the breakpoint window (see 
photo 1). While the breakpoint window 
is active, the user can enable, disable, 
remove, and add breakpoints. To deter- 
mine where to set a breakpoint, the 
user can examine local and global vari- 
ables from the view-variables window 
(see photo 2). 

Breakpoints can trigger when the 
target program reaches a specified line 
of source or assembly code, a variable 
has a stated value, or an expression is 
true. In Turbo Debugger, the term 
breakpoint encompasses the CodeView 
concepts of breakpoint, watchpoint, 
and tracepoint. 
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An unconditional breakpoint is. 

a specific place in the program code 
where execution is to stop. A condi- 
tional breakpoint stops program execu- 
tion only when a certain condition is 
true, such as when a variable has a 
given value or the program changes a 
value in memory. Turbo Debugger’s 
conditional-breakpoint expressions are 
stated in the syntax of the source lan- 
guage (C, Pascal, or assembly) and can 
be conditioned on either an expression 
being true or a change in a variable. 

A watchpoint evaluates a value of 
an expression and stops the program 
when the expression is true. A trace- 
point checks all specified program vari- 
ables or memory-referencing expres- 
sions for changes after each instruction 
executes. 

The CPU window provides an all- 
in-one machine-level view of the target 
program. It has separate panes for dis- 
assembled instructions, registers, flags, 
stack values, and data. The user can 
also create multiple windows, each dis- 
playing a separate code or data area. 

The dump window displays data in 
memory, as referenced by the current 
data-segment register of the target pro- 
gram. The user can search for and 
change a value in memory from the 
dump window. Data formats include 
byte, word, long, comp, float, real, dou- 
ble, and extended. In byte format, each 
byte is accompanied by its ASCII char- 
acter representation. Turbo Debugger 
also displays data in any floating-point 
format supported by Borland compilers 
(including Turbo Pascal real) and any 
IEEE format supported by an Intel 
80x87 math coprocessor. 


The developer selects a source- 
code module (including the main mod- 
ule and any source files) for viewing 
and debugging through the module 
window. From this window, the devel- 
oper can easily see the assembly code 
that corresponds to the source code by 
accessing the CPU window. This feature 
is a distinct advantage over CodeView, 
where the user has to scroll through 
assembly code to find the correspond- 
ing source code. 

Turbo Debugger lists all. variables 
in a program that have global scope, 
including function or procedure names, 
in the left-hand pane of the variables 
window. The right-hand pane displays 
all variables local to the current func- 
tion or procedure. The window dis- 
plays the current values of all variables 
in the format known by the source 
program. The value associated with a 
function name is a pointer, for exam- 
ple, and the value of a Turbo Pascal 
string variable is ASCII text surrounded 
by single quotes. 

The package displays Turbo Pascal 
Boolean and enumerated data types 
with their source-code values as well as 
their integer equivalents; the values of 
Boolean variables are either true or 
false. Because the debugger displays 
data structures as aggregates of simple 
variables, the developer cannot change 
an entire data structure. However, ele- 
ments of an array or data structure can 
be modified individually. 

To see the status of and set and 
reset unconditional or conditional 
breakpoints, the developer accesses the 
breakpoint window. The F2 key is a 
quick way to toggle an unconditional 
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breakpoint anytime at a source- or as- 
sembly-code line where the cursor is 
positioned. The user can set condi- 
tional breakpoints based on either a 
change in a variable or an expression 
being true. Either makes the program 
run slowly because the debugger evalu- 
ates the breakpoint condition after 
single-stepping through each instruc- 
tion and should be used sparingly, gen- 
erally after stopping the program in a 
presumed problem area with an un- 
conditional breakpoint. 

The Turbo Debugger mechanism 
used for managing breakpoints is sim- 
ple, is menu driven, and, unlike Code- 
View, does not use a command syntax 
for setting conditional breakpoints. The 
developer enters the expression that 
controls a conditional breakpoint into a 
pop-up window in the syntax of the 
language selected from the debugger 
option pull-down menu. Conditional 
breakpoints based on changes in vari- 
ables also are entered into a pop-up 
window. 

Turbo Debugger users can moni- 
tor simple variables or data structures 
in the watch window. The value of a 
watch variable is updated within the 
watch window while a program runs 
under control of the debugger. If the 
target program is running on a system 
with an 80x87 math coprocessor, the 
user can inspect, clear, and alter as 
many as eight 80-bit floating-point stack 
registers and 19 flags through the math 
coprocessor window. 

The helpful user-screen function 
permits the user to see the actual 
screen the executing program would 
display at any given moment. Pressing 
Alt-F5 toggles between the user screen 
and the debugging screen. 


LEARN FROM EXPERIENCE 

Finding the bugs and examining the 
Turbo Pascal runtime library and DOS 
programs are easy tasks. For source- 
level debugging, the relationship be- 
tween source and assembly code is 
readily apparent, particularly with the 
Turbo Debugger options to view either 
one or both. Turbo Debugger was in- 
stalled on a PC Designs 8-MHz Turbo 
AT with an Atronics EGA+ video con- 
troller, a 16-MHz IBM PS/2 Model 80, 
and a Compaq 386/20. The package 
performed well when used to debug 
programs with several usual and some 
not-so-common problems. 

Uninitialized variables. A source-code 
analyzer that executed correctly when 
compiled with Turbo Pascal 3.01 pro- 
duced unexpected results with Turbo 
Pascal 5.0. Within 10 minutes, Turbo 
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Debugger pinpointed an uninitialized 
variable that caused the problem. An 
unconditional breakpoint was set in a 
procedure where the problem was sus- 
pected, and the code was traced, 
watching the values of variables related 
to the symptom. The .COM file format 
of Turbo Pascal 3.01 had initialized the 
variable to zero, masking the logic 
error in the program. Without a debug- 
ger, a developer would have to analyze 
the source-code structure, which is less 
likely to pinpoint the problem and can 
be difficult and time-consuming. 
Incorrect variable types. Julian date- 
translation procedures converted from 
Turbo Pascal 3.01 reals to 5.0 long inte- 
gers failed when called by a production 


The Turbo Debugger mech- 
anism for managing break- 
points is simple, menu 
driven, and does not use a 


command syntax. 
a 


program, but worked when called by a 
test program. Turbo Debugger’s two 
views of the variables revealed that the 
production program called the func- 
tions by passing integer variables rather 
than long-integer variables. 

Cooling hot spots. Turbo Debugger 
helped optimize the hot spot (a pro- 
cessor-intensive area) of a statistical 
analysis package. To view the generated 
assembly code, the .EXE program was 
loaded under control of Turbo Debug- 
ger; the source file for the procedure 
being optimized was selected. The cur- 
sor was then moved to the source lines 
being optimized, the CPU window was 
accessed, and the code generated by 
the compiler was inspected. As changes 
were made to optimize a major loop in 
the source code, the debugger dis- 
played the corresponding assembly 
code. This comparison allowed exami- 
nation of the clock cycles required for 
the generated code until a practical 
minimum was reached. 

PC Tech Journal’s OPTZTEST.PAS 
program, designed to test common 
code optimizations, was speeded up 
using Turbo Debugger to see what 
code Turbo Pascal generates (see photo 
3). OPTZTEST (available for download- 
ing on PCTECHline) uses the standard 
Turbo Pascal Move procedure to move 
information in memory quickly. The 


code in the Move procedure within the 
runtimes linked into the application 
was viewed. The Move procedure al- 
ways does slower 8-bit moves (REP 
MOVSB) rather than fast 16-bit moves 
(REP MOVSW) for all but the odd byte 
being moved. A faster procedure was 


| substituted for Move, resulting in a 50- 


percent reduction in processor time for 
moving data and a nominal increase in 
.EXE file size (see photo 4). 

Dissecting FORMAT. The statistical analy- 
sis software mentioned above can mon- 
itor and count INT 13H disk BIOS calls; 
however, it failed to show disk activity 
for the DOS 3.3 FORMAT command 
when formatting a 3.5-inch diskette. 
Turbo Debugger verified that FORMAT 
does not use the INT 13H disk BIOS in 
this case. FORMAT was loaded under 
the control of Turbo Debugger, and 
unconditional breakpoints were set on 
INT 13H instructions. 

On a 5.25-inch diskette, one break- 
point for each track was formatted with 
an INT 13H, AH = 05H (format track). 
When a 3.5-inch diskette was formatted, 
no INT 13H breakpoints were encoun- 
tered. Turbo Debugger’s Search func- 
tion found the INT 13H instructions 
quickly; this could not be done with 
CodeView, because it cannot search for 
assembly-level instructions. 

The arguments must be exact 
when the Turbo Debugger search func- 
tion is used to find code in memory. 

A useful addition to Turbo Debugger 
would be the ability to search for oc- 
currences of a symbolic operand (op) 
code, regardless of its hexadecimal 
value. This would make it easy to 
search FORMAT.COM for all OUT in- 
structions, with any value from the 

set OEOH, 0E7H, OEEH, or OEFH. 

Bugs in the debugger. A minor malfunc- 
tion occurred during testing. When 
TDH386 was run with the command- 
line arguments FORMAT B:, FORMAT 
did not find the B: argument, indicating 
that the 386 version of the debugger 
may not be setting up the program seg- 
ment prefix of the target program cor- 
rectly. The non-386 Turbo Debugger 
performed correctly under the same 
conditions. Borland technical support 
said the problem will be corrected, but 
would not commit to a definite date. 


SUPPORTING PLAYERS 

Several utilities play important support- 
ing roles for Turbo Debugger. After 
debugging is complete, the TDSTRIP 
utility removes symbol-table informa- 
tion from .EXE files, which eliminates 
the need to recompile a program to 
get a finished product. 
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TURBO DEBUGGER 
PHOTO 3: CPU Status | 


PHOTO 4: Assembly Code Implementation 


ee View un = breakpois il . File a aie 
ag 80385 = * “PU 80 : — srr = 
DPIZTEST.83:  lVector{6] := 1; { See hou subsimeemattt, 761C:1143 BBDC nov bx,sp ax 0064 |c=0/ 


cs:01D5 €70678800100 nov  vord ptr £007 
jOPIZTEST.84: [Wectorliz] := 2; { i2 renains 
cs:O1DB 8B3E5606 nov = di, (8056) 
cs:OiDF DLE? shl di,t 
j cs:O1E1 €78578600260 nov  uord ptr [dis 
HOPIZTEST.85:° WWectorf{iz} := 2: { see vhat re 
cs:O1E? 8B3ES600 nov di, £6056) 
j cs:O1EB D1IE7 shl di, 

i cs:S1ED C78570860200 nov word ptr [di+ 
pOPIZTEST.86: IVector£[2} := 3; 
es:O1F3 €76674060306 nov 
JOP TZTEST .88: 


701C:1145 BCDA nov 
7010:114?7 36057768 Ids 
j910: 1148 J6C47FO6 les 
j7O1C:114F 368B4F04 nou 
pO1C: 1153 FC eld 
p?O1C 21154 SBF? cnp si, di 
17011156 7307 jnb =: 115F 
pO1C:1158 O3F1 adds Si, cx 
H01C: 115A 83F9 add = di, cx 
1701C:11.5C: 4E : dec ¢si 
H?01C: 115) 4F dec di 
j701C:115E FD std 


bx 0604 
cx 8O3E 
dx 0800 | 
si 068A 


| 
di 0064 | 
a an 


dx,ds 

si,ss:{bx+0A] 
di,ss:{bx+66) 
cx,ss:[bx+04} 


bx 6001 

cx 093E 

dx 6006 

si 068A 

di 0064 

bp 3FFC bp 3FFC 

sp 3FFE sp 3FFE 
ds 6F7A )): 

es 6F7A | | 

ss 716E 

cs 6F8A 

j 


ip O15E 


ds 6F7A 
es 6F7Ai 
ss 716E 
cs 6F8A 
ip @15E 


: word ptr [007 
i3 := 1 + 2: { Test constant ar 


i ds:6000 CD 26 83 85 06 9A FO FE = da =e 
j ds:0008 1D FO 60 03 AF 45 2D 03 += 9>E-¢ 
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ss :3FFEO068 


ea a ten rte er rae 
ee ee | 
SF Scan ee Da? any Cah .', Yo 13 rn 2 ee “oy PORE NR = \ va 
She i. . at r3-fiod f ad sii . FS-lser Fo: ind 3 woes 
P28 bcs 2 4 aw Mobs Sh + 


Disassembled machine code generated by Turbo Pascal 
overlays the related source code in the CPU window, 
whose five panes include stack, registers, flags, code, and a 
data pane of raw data in the area of memory selected. 


Another view of the CPU window shows the underlying as- 
sembly-code implementation of a Move procedure call in 
Turbo Pascal. This kind of analysis by Turbo Debugger can 
help in making decisions optimizing performance. 


If a program that was compiled 
with a non-Borland compiler is linked 
with .MAP files, the TDMAP program 
appends the .MAP information to the 
.EXE file in Turbo format. The user can 
then debug these programs with Turbo 
Debugger. With TDMAP, developers 
also can use Turbo Debugger on Turbo 
Pascal 4.0 programs. The steps to do 
this are as follows: 

* Compile Turbo Pascal 4.0 program 
with /$T+ command-line option to 
create a .TPM file. 

¢ Create a .MAP file from the .TPM file 
using the Turbo Pascal 4.0 utility, 
TDMAP. 

¢ Run TDMAP to combine the .EXE file 
with information from the .MAP file 
into Turbo Debugger format. 

Another worthwhile utility, TDUMP 
(which Borland calls a module dis- 
assembler), is actually a file analyzer 
that breaks down the structures of 
programs, object files, and libraries. 
TDUMP does not disassemble code, but 
relies on the debugger to do so. For 
programs, TDUMP decodes the .EXE 
file header and shows the initial stack 
segment address, the program entry 
point, and all addresses requiring 
loader relocation. 

For object files, TDUMP formats 
the segment definition information, 
PUBLIC symbols, and locations requir- 
ing linker fix-ups. The utility also dis- 
plays the contents of all data and code 
segments in hexadecimal format. For 
libraries, which are collections of ob- 
ject files, TDUMP shows the same .OBJ 
information and some library-specific 
information. 
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If a file is not in one of these 
three formats, TDUMP simply prints a 
file dump in hexadecimal, ASCII, or 
both. It does not analyze the structure 
of Turbo Pascal 5.0 .TPU or .TPL files, 
which are the equivalent of libraries in 
other languages. No Turbo Debugger 
utility is provided to accomplish this 
task, but TDUMP does give a straight 
hexadecimal readout of the files. 

The TDPACK utility reduces the 
size of the debugging information ap- 
pended to the executable code of an 
EXE file. For example, a 55KB file 
compiled with debugging information 
grew to 115KB. TDPACK eliminated 
about 9,000 bytes of duplicate informa- 
tion, such as strings and data-type in- 
formation. If Turbo Debugger runs out 
of memory while debugging a large 
program, running TDPACK could help. 
All the utilities display a list of options 
when started without a command-line 
argument. 

The Turbo Debugger User's Guide 
is well written and detailed, covering 
installation and overall operation. The 
bulk of the guide explains operation 
details, such as examining and modify- 
ing files and data, setting breakpoints, 
and evaluating breakpoint and watch 
expressions in the target program’s 
source language. Several chapters ex- 
plain the nuances of debugging pro- 
grams at the assembly level and debug- 
ging with an 80x87 coprocessor. 


AN EXCELLENT VALUE 

Finding bugs in software is a complex 
task. While no software can replace 
careful analysis, high-level language 


debuggers provide an invaluable aid. 
With Turbo Debugger, the developer 
can work in the familiar high-level 
source-code environment, but can eas- 
ily drop down to compiler-generated 
machine instructions. 

Turbo Debugger is a solid addition 
to any software developer's toolbox 
and rounds out Borland’s programming 
product line. It has many attractive fea- 
tures including an easy-to-use interface; 
close integration with Turbo C and 
Turbo Pascal; the ability to debug 
CodeView-compatible .EXE files; and 
the capacity to debug very large pro- 
grams, either on a 386-based PC or 
remotely, using two PCs. 

Moreover, the package is a bar- 
gain. Borland sells Turbo Assembler 
and Turbo Debugger bundled together 
for $149.95. Turbo Debugger is in- 
cluded with Borland’s Professional 
Turbo C and Professional Turbo Pascal; 
both packages sell for $250.00 each. 
Current users of Turbo C or Turbo Pas- 
cal can upgrade to the Professional 
packages for $99.95 each. =| 
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